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FOREWORD 


This  paper  describes  a  Fleet-first  methodology  to  generate  Data  Model  2-compliant 
architectures  and  use  them  to  improve  strategic  and  tactical  readiness.  Architectural  design 
originates  with  mapping  key  capabilities  to  desired  effects  articulated  by  identified  operational 
stakeholders,  which  lends  the  methodology  to  a  Fleet-first  perspective  versus  a  system-  or 
technology-first  perspective.  Capability-Based  Modeling  Methodology  identifies  best  practices 
for  executing  development  of  a  “Fleet-first”  architecture,  and  explains  how  each  core  model  aids 
in  managing  specified  data  types  and  relationships.  The  paper  concludes  by  discussing  impacts 
on  mission  engineering  from  following  a  Fleet-first  methodology. 
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1,0  BACKGROUND 

Architectures  have  been  recognized  as  useful  for  managing  the  complex  relationships  among 
differing  data  types  dating  back  to  the  development  of  the  original  Zachman  framework,  first 
proposed  by  John  Zachman  in  1982  for  automating  system  design.  Within  two  decades,  the 
Department  of  Defense  (DoD)  had  made  progress  toward  integrating  architectures  into  defense 
acquisition  processes  to  aid  in  better  Joint  system  designs.  Problems  with  integration  and 
interoperability  (I&I)  have  flourished  with  the  sharp  rise  in  technological  complexity  of  warfare 
systems  acquired,  deployed,  and  used  throughout  the  Fleet,  yet  the  use  of  architectural  design 
tools  and  processes  have  been  slow  to  evolve.  The  DoD  has  reacted  to  these  issues  by 
establishing  updated  DoD-wide  acquisition  guidance  and  creating  organizations  responsible  for 
defining  I&I  processes.  To  adequately  execute  these  I&I  processes  a  new.  Fleet- first  architectural 
methodology  is  required  to  aid  in  consolidating  data  and  data  needs  across  a  diverse  group  of 
Joint  and  coalition  stakeholders. 

The  Capability-Based  Modeling  Methodology  (CBMM)  was  developed  through  multiple 
architectural  efforts  to  document  how  the  Fleet  conducts  naval  operations  and  how  it  uses 
available  systems  and/or  services  to  achieve  a  stated  desired  effect.  By  using  the  CBMM 
approach  to  building  mission  architectures,  architects  can  increase  the  efficiency  at  which  they 
organize,  scope,  and  investigate  current  I&I  issues.  This  approach  also  creates  a  mechanism  that 
encourages  the  utility  and  reuse  of  architecture  tools  and  products  throughout  the  mission 
engineering  and  acquisition  management  process.  CBMM  development  originated  in  the  Navy 
enterprise  but  is  intended  for  application  in  both  Joint  and  coalition  organizations. 

1.1  Mission  Engineering 

Mission  engineering  involves  planning,  analyzing,  organizing,  and  integrating  emerging 
operational  concepts  to  specify  the  end-to-end  mission  architecture  attributes  across  the  doctrine, 
organization,  training,  material,  leadership,  personnel,  and  facility  (DOTMLPF)  spectrum.  These 
mission  architectures  inform  the  communities  of  interest  involved  in  fulfilling  mission  needs 
statements,  and  aid  in  identifying  how  material  and  non-material  entities  contribute  to  Fleet 
readiness. 

To  achieve  the  stated  objectives  of  mission  engineering,  a  significant  amount  of  data  must  be 
identified,  collected,  analyzed,  and  updated.  Data  identification  requires  engineers  understand  the 
causes  and  effects  contributing  to  the  achievement  of  the  Fleet’s  desired  effect  for  a  specified 
mission  area.  Data  collection  is  the  activity  associated  with  learning  and  understanding  how  a 
desired  effect  is  achieved.  Data  analysis  is  the  process  of  investigating  potential  problems  or 
inefficiencies  experienced  by  the  Fleet  while  operating  toward  its  desired  effect.  Updating  data  is 
the  process  of  applying  lessons  learned  to  the  Fleet  enterprise,  whether  it  be  for  evolving  the 
material  or  non-material  understanding  of  the  mission.  Each  of  these  activities  requires  vast 
amounts  of  information  and  a  comprehensive  understanding  of  how  each  data  element  relates  to 
another.  Data  identification,  collection,  and  analysis  are  necessary  activities  and  processes  for 
assessment  of  developed  capabilities  and  evaluation  of  desired  capabilities  that  are  fundamental 
to  achieving  the  objectives  of  mission  engineering.  Figure  1  illustrates  this  concept. 
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Figure  1:  Conceptualizing  Mission  Engineering  and  its  Relationships  to  DOTMLPF  Requirements 


This  data  management  requirement  is  the  key  purpose  of  architecture,  dating  back  to  its 
inception.  Current  Department  of  Defense  Architecture  Framework  (DoDAF)  instruction 
identifies  a  data  model  and  how  dozens  of  architecture  viewpoints  may  be  used  to  manage  the 
identified  data  relationships.  Because  of  DoDAF’s  wide  appeal  to  an  organization  as  diverse  as 
the  DoD,  it  does  not  specify  particular  approaches  for  developing  or  tailoring  architectures 
toward  a  particular  use,  such  as  modeling  Fleet  operations.  Though  several  prominent 
architectural  methodologies  exist,  none  specifically  address  how  architectures  may  be  used  to 
adequately  manage  data  required  to  investigate  Fleet  operations  and  readiness. 


1,2  Mission  Architecture 


The  Navy,  as  well  as  the  DoD  as  a  whole,  faces  numerous  issues  today  regarding  problems  in 
system  integration  throughout  the  Fleet  and  interoperability  among  deployed  technologies. 
Problems  also  exist  with  the  maturation  and  development  of  training,  doctrine,  and  policies  taken 
toward  current  and  emerging  threats.  Combined,  these  deficiencies  represent  causation  for 
degraded  Fleet  readiness  against  present  and  future  threats.  These  problems,  particularly  those 
associated  with  Fleet  acquisitions,  are  mitigated  in  part  by  responsible  systems  engineering 
practices  and  by  new  regulations  established  to  guide  system  development  and  integration  with 
the  current  Fleet.  Still,  the  quantity  and  quality  of  data  that  systems  engineers  and  Fleet 
advocates  are  confronted  with  becomes  difficult  to  manage  without  using  a  data  management 
tool  such  as  an  architecture.  When  built  for  this  purpose,  the  architecture  becomes  otherwise 
known  as  a  mission  architecture. 


Mission  architecture  continues  to  become  an  increasingly  recognized  role  in  system 
development  and  acquisition.  CBMM  development  was  initiated  as  a  result  of  ongoing  Navy 
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efforts  to  evolve  current  acquisition  practices  and  solve  problems  in  requirements  definition  and 
system  development  that  often  result  in  inefficient  I&I. 

CBMM  focuses  on  a  Fleet-first  approach,  meaning  it  specifies  architectures  must  begin  from 
the  Fleet’s  needs  and  desired  outcomes  to  a  specific  mission  or  strategic  operation.  Relationships 
between  tasks  and  systems  are  drawn  in  context  of  a  single  or  set  of  capabilities  that  allows 
senior  leadership  to  understand  which  systems  are  being  used  to  support  essential  tasks  that 
contribute  to  a  specific  desired  effect.  These  relationships  provide  a  vehicle  for  analysis  of 
current  and  future  Fleet  issues  that  threaten  warfighters’  state  of  readiness. 

1.3  DODI5000.02 

Department  of  Defense  Instruction  (DoDl)  5000.02,  “Operation  of  the  Defense  Acquisition 
System,”  is  a  policy  endorsed  by  the  Under  Secretary  of  Defense  for  Acquisition,  Technology, 
and  Logistics  (USD[AT&L]),  the  Assistant  Secretary  of  Defense  for  Networks  and  Information 
Integration  (ASD[N11]),  and  the  Director  of  Operational  Test  and  Evaluation  (DOT&E),  Office 
of  the  Secretary  of  Defense.  DOD15000.02  provides  guidance  and  governance  for  DoD 
acquisitions,  and  identifies  a  need  for  a  capability-based  technology  needs  definition; 

“[This  instruction]  Establishes  a  simplified  and  flexible  management  framework  for 
translating  capability  needs  and  technology  opportunities,  based  on  approved  capability 
needs,  into  stable,  affordable,  and  well-managed  acquisition  programs  that  include 
weapon  systems,  services,  and  automated  information  systems  (AlSs).” 

Eurthermore,  DoD15000.02  requires  all  capability  needs  and  acquisition  management 
systems  shall  use  “integrated  architectures”  to  conduct  DOTMLPE  analyses.  By  addressing 
DOTMLPE  solutions,  DoD15000.02  lays  the  groundwork  for  integrating  activities  across  the 
Navy,  from  Elect  organizations  to  Systems  Commands  (SYSCOMs).  The  instruction  goes  on 
further  to  empower  milestone  decision  authorities  to  determine  whether  sufficient  information 
has  been  provided  to  advance  program-of-record  development.  Through  the  pursuit  of  mission 
architecture  using  a  Elect-first  approach,  CBMM-compliant  architectures  can  better  inform 
milestone  decision  authorities  and  aid  in  determining  which  material  or  non-material  solutions 
are  best  suited  to  address  needs  identified  in  initial  capabilities  documents.  These  architectures 
also  inform  internal  and  external  oversight  organizations  of  the  state  of  enterprise  readiness  for 
new  DoD  acquisitions  that  supports  compliance  with  net-ready  key  performance  parameters. 

With  the  signing  of  DoD15000.02,  architectures  require  entrance  criteria  into  the  production 
and  development  phase  of  the  Defense  Acquisition  System.  Because  CBMM  begins  with  a  Elect- 
first  approach  to  map  into  system  functionality  and  overall  mission  performance,  it  provides  a 
comprehensive  methodology  for  satisfying  these  requirements  and  ensuring  that  architectures 
can  appropriately  manage  data  needed  to  guide  requirements  definition,  M&S  specification,  and 
anticipate  future  l&l  issues  with  the  existing  or  future  Elect. 

1.4  Signing  of  I&I  Charter 

In  December  2012,  an  I&I  charter  was  signed  by  the  Vice  Chief  of  Naval  Operations  to 
establish  an  office  in  the  Office  of  the  Chief  of  Naval  Operations  that  would  be  responsible  for 
developing  methods  and  approaches  to  assess  “I&I  gaps  from  a  mission  area  kill/effects  chain 
perspective.”  With  this  charter,  I&I  funded  organizations  were  commissioned  to  assess  current 
Elect  capabilities  and  determine  the  effects  of  emergent  technologies  on  the  existing  enterprise. 
The  charter  also  establishes  governance  and  a  battle  rhythm  for  future  I&I  tasking. 
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The  I&I  charter,  similar  to  DoDI5000.02,  while  extremely  effective  in  establishing  mission 
engineering  as  a  core  Navy  competency,  does  not  specify  a  methodology  or  approach  to  be  taken 
for  architectural  development.  This  is  largely  owing  to  the  inexperience  of  many  organizations  to 
model  Fleet  operations  using  architectures.  By  exploring  multiple  approaches  to  architectural 
development  in  Navy  I&I  and  alongside  Fleet  organizations,  CBMM  has  evolved  from  a  concept 
to  a  repeatable  practice  that  satisfies  the  mission  architecture  needs  articulated  in  the  I&I  charter. 
CBMM,  by  modeling  the  complete  context  of  Fleet  desired  effects,  produces  an  architectural 
approach  that  supports  the  I&I  goal  of  relating  data  relevant  to  current  Fleet  readiness  and  the 
impact  of  current  or  future  DOTMLPF  solutions  on  the  existing  enterprise. 

2.0  FLEET-FIRST,  CAPABILITY-DRIVEN  MISSION  MODELING 


Given  the  complexity  of  managing  mission  data,  conceptual  aids  are  useful  to  describe 
CBMM  as  an  architectural  approach  and  to  address  how  it  accommodates  the  interests  of 
multiple  Navy  enterprise  stakeholders.  A  data  model  is  also  essential  to  identify  diverse  data  type 
relationships  and  which  core  models  are  most  useful  for  data  management  functions. 


2,1  Acquisition  Triad 

DoD  acquisitions  can  be  conceptualized  through  a  three-sided  figure  representing  the  Fleet 
and  Department  of  the  Navy  (DON)  leadership,  the  operational  community,  and  the  technical 
community  as  modeled  in  Figure  2. 


FLEET 
CAPABILITY 
DOMAIN 

What  capability 
does  the  Fleet 
endeavor  to 
achieve? 


Enables  Achievement  Of/ 


Evaluated  Based  On 


Requires  Performance  Of 
Developed  to  Achiev^ 


OPERATIONAL 
DOMAIN 

What  actions  must 
operators  and 
platforms  take? 


\Requires  Specified  Function  Of^ 


Enables  Performance  Of 


TECHNICAL 
DOMAIN 

What  systems 
must  be  deployed 
and  what 
functionality  must 
They  possess'A 


Figure  2:  Acquisition  Triad 


This  triad  demonstrates  the  interdependence  that  exists  among  all  stakeholders  in  Navy 
acquisitions  and  in  the  several  Navy  communities  of  interest.  This  same  construct  can  be  used  to 
describe  non-Navy  organizations  but  will  be  limited  in  this  report  to  the  DON. 

Each  node  represents  group  or  organizational  interests,  which  for  many  organizations  may 
mean  many  stakeholders  across  multiple  domains.  The  triad  becomes  most  useful  in,  first. 
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identifying  the  nature  of  an  organization’s  interests  and,  second,  in  associating  the 
interdependence  that  exists  among  these  interests.  Once  an  understanding  is  reached  that 
seemingly  unrelated  interests  are  related,  it  becomes  easier  to  begin  the  process  of  identifying 
essential  data  elements  required  to  comprehensively  model  the  enterprise. 

Needlines  between  nodes  represent  this  interdependence.  The  CBMM  purpose  is  not  to 
establish  these  relationships  but  rather  to  identify  and  augment  the  current  state  of  cooperation 
among  interests.  For  example.  Joint  Urgent  Operational  Needs  (JUON)  statements  are  used  to 
articulate  requirements  of  the  Fleet  Capability  Domain  to  the  Technical  Domain  for  the  purpose 
of  a  material  solution.  These  statements  provide  great  deals  of  information  to  the  technical 
community  but  may  not  be  sufficient  for  producing  the  “right  thing”  for  the  “right  problem.” 
CBMM  architectures  allow  for  identification,  collection,  and  analysis  of  the  problem  expressed 
in  these  JUONs  so  clearer  requirements  can  be  delivered  to  the  engineers  and  a  better,  more 
efficiently  integrated  solution  can  be  delivered  to  warfighters. 

2.1.1  Fleet  Capability  Domain  Perspective 

Fleet  capabilities  and  known  gaps  are  managed  and  prioritized  in  higher  Navy  echelons.  Part 
of  this  prioritization  occurs  as  a  result  of  the  known  development  of  current  systems  (represented 
by  the  “Developed  to  achieve”  needline  originating  from  the  technical  domain)  and  from  the 
current  status  of  existing  Fleet  readiness  (represented  by  the  “Enables  achievement  of’  needline 
originating  from  the  operational  domain).  Fleet  capabilities  drive  material  development  through 
requirements  definition  (represented  by  the  “Requires  performance  of’  needline)  and  guide  the 
evolution  of  doctrine  and  training  through  iteratively  evaluating  existing  procedures  (represented 
by  the  “Evaluated  based  on”  needline). 

2.1.2  Operational  Domain  Perspective 

The  operational  domain  includes  those  stakeholders  responsible  for  executing  defined 
capabilities  using  established  training,  existing  platforms  and  systems,  and  current  doctrine. 

Their  actions  are  limited  by  material  readiness  (“Enables  performance  of’  needline)  and  guided 
by  doctrine  and  priorities  established  by  senior  DON  leadership  (“Evaluated  based  on”).  The 
operational  domain  relies  on  the  technical  domain  to  develop  and  deploy  systems  capable  of 
supporting  operations  in  defined  environments  and  conditions  (“Requires  specified  function  of’ 
needline).  The  operational  domain  also  interacts  with  fleet  leadership  through  evaluation  of  its 
ability  to  achieve  specific  capabilities  (“Enables  achievement  of’  needline),  which  provides 
feedback  to  naval  leadership  regarding  fleet  readiness.  Through  assessment  of  current  fleet 
readiness,  leadership  then  refines  capability  needs  to  senior  strategic  planners  who  redirect 
technical  priorities  (“Requires  performance  of’  needline). 

2.1.3  Technical  Domain  Perspective 

The  technical  domain  is  primarily  concerned  with  developing,  improving,  or  maintaining 
material  solutions  to  capability  gaps  established  by  the  fleet  capability  domain.  Traditionally, 
limited  iterative  interaction  exists  between  the  fleet  and  the  SYSCOMs  (“Requires  performance 
of’  needline),  which  can  result  in  system  requirements  that  lack  the  technical  rigor  or  operational 
context  to  provide  what  warfighters  truly  need  or  are  capable  of  employing.  SYSCOMs  work  to 
develop  systems  to  their  design  requirements  established  by  Navy  leadership  (“Developed  to 
achieve”  needline).  Unfortunately,  due  to  the  complex  and  ever-changing  nature  of  war, 
requirements  that  are  either  not  developed  using  a  rigorous  engineering  approach  or  fail  to 
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address  the  evolving  state  of  naval  warfare  risk  produce  material  solutions  that  do  not  efficiently 
integrate  with  the  Fleet  or  do  not  suitably  meet  the  operational  domain’s  need. 

The  risk  of  insufficient  or  incomplete  requirements  definition  is  directly  related  to  the  ability 
of  the  Navy  enterprise  to  share  and  understand  information.  The  data  exchange,  performed 
without  the  aid  of  a  tool  such  as  mission  architecture,  can  become  overwhelming  and  difficult  to 
maintain. 

CBMM  provides  a  vehicle  for  capability,  operational,  and  technical  collaboration.  It  also 
provides  a  vehicle  for  the  technical  community  to  validate  its  material  solutions  with  the  Fleet 
prior  to  and  during  system  testing  (“Requires  specified  function  of’  needline)  and  increases  the 
likelihood  the  delivered  system  integrates  with  the  Fleet  (“Enables  performance  of’  needline) 
without  requiring  extraneous  training  or  inefficient  post-development  integration  measures. 

2,2  Symbiotic  Relationships  Between  Domains 

The  acquisition  triad  is  built  to  not  only  communicate  types  of  interest  each  stakeholder  takes 
in  the  mission  but  also  the  relationships  between  those  stakeholders  (see  Figure  3). 


Figure  3:  Application  of  Acquisition  Triad  to  Current  Navy  Activities 


As  discussed,  the  relationship  between  the  Fleet  capability  domain  and  the  technical  domain 
exists  in  requirements  definition  and  satisfaction  by  way  of  material  solutions.  The  relationship 
between  the  technical  and  operational  domains  can  be  found  in  the  verification  and  validation  of 
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material  solutions  and  the  deployment  of  new  systems  entering  initial  operational  eapability  or 
relevant  operational  testing.  The  relationship  between  operational  and  Fleet  capability  domains 
exists  throughout  United  States  Fleet  Forces’  calendar  of  Fleet  experimentation  and  training 
events  as  well  as  in-service  Fleet  readiness  reports.  Collectively,  this  forms  a  symbiotic 
relationship  among  members  of  all  three  domains  and  speaks  to  the  need  for  a  modeling 
approach  that  can  manage  the  resources  and  needs  of  all  stakeholders. 

The  triad  makes  no  efforts  to  represent  the  strength  of  each  relationship,  either  in  theory  or 
practice.  The  Fleet  capability  and  operational  domains  often  consist  of  similar  organizations  that 
share  common  interests  that  strengthen  their  relationship.  The  technical  domain  does  not  share 
the  same  organizational  ties  to  warfighters  that  operational  and  capability  domains  share.  For 
example,  SYSCOMs  operate  under  a  management  structure  not  dissimilar  to  Fleet  organizations 
but  are  not  tied  to  any  particular  Fleet  or  operational  organization.  This  introduces  a 
communication  barrier  among  those  in  the  technical  domain  who  may  not  clearly  understand 
operations  but  are  still  responsible  for  developing  systems  for  key  operational  stakeholders.  This 
lack  of  interaction  with  the  Fleet,  paired  with  a  mentality  that  the  “customer”  is  the  organization 
that  provided  an  initial  list  of  system  requirements,  results  in  fielded  systems  that  do  not  fully 
support  warfighters  in  the  manner  theater  commanders  want  to  fight  or  satisfies  all  system 
requirements  with  the  exception  of  employment;  often  unpredictable  at  the  time  of  initial 
requirements  definition. 

2,3  Data  Model 


A  data  model  was  created  for  tasks  established  in  the  I&I  charter  to  map  complex  data 
relationships  managed  in  mission  architecture.  This  model,  referred  to  as  the  Integrated 
Capability  Framework  (ICF)  Data  Model,  is  illustrated  in  Figure  4. 
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Figure  4:  ICF  Data  Model 
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The  ICF  Data  Model  is  based  on  DoDAF  Meta  Model  eomplianee  and  the  needs  of  the  ICF 
to  better  inform  aequisition  praetiees  and  requirements  definition.  In  the  CBMM  instantiation  of 
the  ICF  Data  Model,  two  additional  eonneetions  ean  be  drawn:  “System  Funetions”  to  “Mission 
Area  and  Capabilities”  and  “Mission  Foeus,  Seope,  and  Purpose”  to  “Rules  and  Doetrine.”  This 
allows  for  seoping  missions  based  on  eurrent  and  future  doetrine  and  ereates  a  eritieal  data 
relationship  between  eapabilities  and  system  funetions  that  identifies  whieh  material 
requirements  exist  to  aehieve  a  given  eapability.  Some  terminology  from  the  ICF  data  model  has 
been  ehanged  for  ease  of  use  and  understanding  by  arehiteets  not  familiar  with  the  ICF,  as  shown 
in  Figure  5. 


Figure  5:  CBMM  Data  Model 


The  CBMM  data  model  ereates  a  meehanism  that  allows  for  organizing  data  that  eomes  from 
and  is  eonsumed  by  multiple  stakeholders  aeross  all  domains  of  the  aequisition  triad.  Using  this 
data  model,  arehiteets  ean  determine  suitable  methods  for  parsing  and  managing  available  data 
and  data  needs  present  throughout  the  enterprise.  Models  deemed  essential,  or  “eore,”  to  CBMM 
will  represent  eritieal  relationships  identified  in  the  data  model. 

By  superimposing  the  CBMM  data  model  onto  the  aequisition  triad  in  Figure  6,  arehiteets 
ean  relate  speeifie  data  elements  and  relationships  to  individual  stakeholders. 
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Figure  6:  CBMM  Data  Model  Superimposed  ou  Acquisitiou  Triad 
3.0  ARCHITECTURAL  APPROACH 


CBMM  also  specifies  an  architectural  approach  for  manipulation  and  management  of  the 
data  model.  This  approach  uses  readily  available  authoritative  data  sources  from  the  DON,  which 
standardizes  architectural  products  across  multiple  efforts  and  accommodates  product  reuse 
without  the  need  for  costly  reconciliation  of  inconsistent  taxonomies. 

The  following  development  sequence  is  a  suggested  roadmap  to  generating  a  CBMM  mission 
architecture.  Architectures  are  built  in  an  iterative  manner  meaning  that  some  steps  may  be 
conducted  multiple  times.  Data  availability  and  data  needs  may  also  necessitate  some  steps  being 
accomplished  out  of  order.  Regardless,  the  sequence  provided  has  been  useful  in  capturing  Fleet 
operations  and  in  efficiently  managing  data  across  a  multimission  area  enterprise. 

3,1  Summary  and  Overview  and  Scenario  Documentation  (AV-1,  OV-1) 

An  Architectural  Summary  and  Overview  (AV-1)  defines  the  purpose,  goals,  scope,  and 
questions  to  be  answered  by  the  final  architecture  product.  When  built  in  accordance  to 
DODAF  2.0,  the  AV-1  serves  as  a  commonly  understood  product  that  aids  in  coordination 
among  all  domain  stakeholders  for  architectural  scoping  and  development.  CBMM  encourages 
including  references  of  all  data  in  the  AV-1  to  attributed  sources,  sponsors,  stakeholders,  or 
authoritative  sources.  This  discourages  arbitrary  architectural  development  and  creates  a  level  of 
accountability  in  architecture  by  establishing  under  whose  authority  or  expertise  assumptions, 
scope,  or  other  identifying  information  was  established.  To  aid  in  planning  and  execution, 
stakeholders  may  be  aligned  in  the  acquisition  triad  to  help  identify  the  nature  of  data  needs. 
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It  is  common  practice  for  programs  of  record,  Fleet  organizations,  or  system  authorities  to 
develop  Design  Reference  Missions  (DRMs)  to  guide  testing  and  design  evaluation.  CBMM 
eneourages  decomposing  these  DRMs  into  arehiteetural  elements,  applying  the  DRM  seope  to 
the  AV-1  and  the  DRM  deseription  to  the  High-level  Operational  Graphic  (OV-1).  As  required 
by  DoDAF  2.0,  the  OV-1  should  inelude  a  narrative  outlining  the  mission’s  eonditions, 
assumptions,  and  scope  in  suffieient  detail  to  guide  operational  viewpoint  (OV)  development. 
DRMs  may  contain  a  sufficient  level  of  detail  to  serve  as  the  accompanying  OV-1  narrative, 
which  would  enable  an  arehitect  to  directly  import  already  established  DRM  metadata  into  a 
CBMM-eompliant  DoDAF  architeeture,  more  easily  integrating  mission  arehitectures  in  the 
conventional  acquisition  system  or  existing  organizational  proeesses. 

The  AV-1  contains  summary  data  from  every  CBMM  data  model  data  element.  The  OV-1 
eontains  data  (highlighted  in  yellow  in  Figure  7)  regarding  the  mission  to  be  performed, 
capabilities  to  be  achieved,  conditions  under  which  operations  will  oeeur,  and  the  overall  desired 
effect. 


Figure  7:  Primary  OV-1  Data  Elements  in  the  CBMM  Data  Model 


3,2  Capability  Definition  and  Activity  Mapping  (CV-2,  -4,  -6) 

The  Fleet’s  desired  effeet  drives  whieh  eapabilities  and  dependent  capabilities  are  ineluded  in 
the  arehitecture.  If  these  desired  effeets  are  included  in  a  DRM  or  referenee  tactical  situation 
(TACSIT),  then  establishment  of  eapabilities  modeled  in  an  architeeture ’s  eapability  viewpoints 
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(CVs)  becomes  a  matter  of  simply  mapping  desired  effects  to  the  capabilities  listed  in 
authoritative  taxonomies,  such  as  the  Required  Operational  Capability/Projected  Operational 
Environment  or  Joint  Capability  Areas.  Once  capabilities  are  derived  and  mapped  to 
authoritative  sources  (e.g.,  DRMs,  TACSITs),  they  can  be  modeled  in  a  hierarchy  by  using  a 
Capability  Taxonomy  (CV-2).  If  no  authoritative  source  exists  from  which  capabilities  can  be 
derived,  it  is  incumbent  upon  the  architect  to  seek  validation  of  capabilities  from  an  authoritative 
source  or  Fleet  command.  Such  sources  should  be  noted  in  AV-1  and  validated  with  the  intended 
architecture  consumers.  Capability  dependencies  can  often  be  established  using  the  same  set  of 
authoritative  sources  and  documented  in  the  Capability  Dependencies  Description  (CV-4).  Data 
required  for  generating  CV-2,  -4,  and  -6  models  are  highlighted  in  yellow  in  Figure  8. 


Figure  8:  Primary  CV-2,  CV-4,  and  CV-6  Data  Elements  in  the  CBMM  Data  Model 

Before  continuing  to  operational  activity  modeling,  it  becomes  necessary  to  establish 
activities  required  to  satisfy  each  capability  noted  in  the  CV-2.  These  activities  can  be  modeled 
in  a  Capabilities-to-Activities  Description  (CV-6).  This  model  can  traditionally  be  achieved 
through  a  matrix  or  spreadsheet.  CBMM  increases  the  level  of  detail  in  the  conventional  CV-6 
by  including  interactivity  dependency  mappings  required  to  achieve  each  capability.  The 
resulting  model  visually  resembles  an  Activity  Model  (OV-5b)  but  is  scoped  to  a  single 
capability  making  it  satisfy  CV-6  data  requirements. 

Figure  9  is  an  example  of  a  CV-6  created  to  model  activity  relationships  in  a  single  capability 
and  resembles  a  simplified  version  of  an  OV-5b.  The  viewpoint  shows  several  Navy  tactical 
tasks  (NTAs)  connected  to  externally  identified  NT  As  that  exist  in  separate  capability  areas.  In 
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Figure  6,  capabilities  are  taken  from  the  Navy’s  Required  Operational  Capability  established  in 
Office  of  the  Chief  of  Naval  Operations  Instruction  C3501.2K,  (U)  “Naval  Warfare  mission 
Areas  and  Required  Operational  Capability/Projected  Operational  Environment  (ROC/POE) 
Statements.”  NT  As  identified  as  critical  by  the  Elect  via  the  Navy  mission-essential  task  list  have 
been  highlighted  in  gold.  By  producing  a  CV-6  as  an  activity  mapping  scoped  to  a  single 
capability  or  sub-capability,  operations  are  “modularized”  by  capability,  allowing  them  to 
behave  as  building  blocks  for  a  larger  mission  architecture.  This  modularity  has  both 
programmatic  and  architectural  development  advantages  over  more  traditional  approaches. 
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3.2.1  Modularity’s  Impact  on  Future  Effort,  Manning,  and  In  vestment 

Modularity  becomes  increasingly  important  to  the  architect  as  each  viewpoint  goes  through 
validation  and  accreditation  with  stakeholders  and  data  owners.  Conventionally,  architecture 
accreditation  or  validation  becomes  a  difficult  process  that  involves  mapping  all  data  elements  to 
either  authoritative  sources  or  documentation.  This  mapping  represents  a  large  financial  effort 
for  sponsoring  organizations.  If  the  modular  approach  in  CBMM  is  followed,  individual  CV-6 
viewpoints  may  be  accredited  individually.  This  creates  circumstances  where  architectures  can 
be  validated  and  accredited  once  and  reused  for  future  efforts  without  additional  investment. 


As  experienced  throughout  the  Navy  I&I  effort,  architecture  reuse,  through  modularized 
CV-6  viewpoints,  has  a  “stacking  effect”  on  program  investment  savings  over  time,  as  illustrated 
in  Figure  10. 


Figure  10:  Notional  Cost  Saving  of  Modular  CV-6  Design  with  Validation/Certification  Carryover 


The  tradeoff  introduced  by  this  type  of  modular  reuse  is  in  the  validation  of  previous 
architecture  conditions  and  assumptions.  If  a  preceding  architecture  was  developed  under  a 
dramatically  different  set  of  operating  conditions  or  environment,  some  revalidation  may  be 
required.  However,  even  under  these  circumstances,  the  preceding  architecture  is  still  useful  as  a 
starting  point  for  architecture  development  that  results  in  increased  developmental  efficiencies. 

3.2.2  Utiiity  of  CBMM  CV-6  Buiid-up  to  OV  Generation 

A  mission  is  completed  by  achieving  a  series  of  interconnected  capabilities.  These 
dependencies  can  be  identified  and  analyzed  in  the  CV-4.  Since  all  activities  required  to  achieve 
each  capability  are  identified  through  modularized  CV-6  viewpoints,  the  task  of  creating  activity 
models  (OV-5a  and  OV-5b)  becomes  simpler.  Identifying  activity  relationships  becomes  a 
simple  matter  of  merging  activities  required  to  achieve  each  separate  capability  with  the 
dependencies  between  each  capability.  Figure  1 1  illustrates  this  process. 
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Figure  11:  Combining  Modularized  CV-6  Models  Through  CV-4  Capability  Dependencies 

to  Produce  Activity  Models 


3,3  Activity  Models  (OV-5a,  -5b) 

Traditionally,  the  OV-5a  and  OV-5b  would  be  the  first  or  one  of  the  earliest  instanees  in  an 
arehiteeture  where  aetivities  are  defined  and  their  dependeneies  established.  CBMM  differs  from 
eonvention  in  pulling  both  aetivity  definition  and  interaetivity  mapping  from  data  modeled  in 
CV-6  models.  This  developmental  relationship  between  CV-6  and  OV-5  diagrams  forms  one  of 
the  CBMM  produet  eornerstones. 

A  key  CBMM  tenet  is  that  an  aetivity,  without  eontext  of  a  eapability,  is  ambiguously 
defined,  rendering  it  ineffeetive  for  modeling  real-world  operations  or  for  reuse  in  modeling  and 
simulation  (M&S)  or  other  types  of  analysis.  Depending  on  the  desired  effeet,  an  aetivity  may  be 
implemented  and  defined  a  number  of  ways.  This  reality  requires  that  aetivities  be  defined  first 
in  CV-6  models  before  being  mapped  together  in  an  aetivity  model.  The  data  required  to 
generate  the  OV-5  is  highlighted  in  yellow  in  Figure  12. 
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Figure  12:  Primary  OV-5  Data  Elements  in  the  CBMM  Data  Model 

In  practice,  managing  these  types  of  dual  activities  becomes  diffieult.  Current  arehitectural 
tools  are  built  to  support  DoDAF  but  not  neeessarily  built  for  mission  architecture  development; 
vice  enterprise,  organization,  or  system  arehitectures.  This  may  require  a  unique  numbering 
system  or  an  independently  maintained  index  of  activities  as  they  occur  in  different  capabilities. 
Because  of  the  diversity  in  architectural  tools  currently  used  by  different  stakeholders,  it  is  the 
responsibility  of  the  architect  to  ensure  activity  taxonomies  are  properly  managed  to  avoid 
ambiguity  in  activity  definitions  and  interpretations. 


3,4  Determining  Technical  Relationships  to  Activities  (SV-1,  -4,  -5a,  -5h) 

Traditional  architectural  methodologies  begin  generation  of  system  viewpoints  (SVs)  by 
defining  the  systems  of  primary  interest  in  an  Interface  Description  (SV-1)  model.  This  approach 
is  useful  only  when  the  available  systems  are  highly  controlled.  Unfortunately,  Navy  missions 
may  use  multiple  baselines  of  common  systems  as  well  as  many  systems  irrelevant  to  the  current 
arehiteetural  effort.  The  architect’s  systems  of  primary  interest  are  dictated  by  the  activities  and 
performers  necessary  to  achieve  the  desired  effect. 

Therefore,  the  CBMM  approach  of  defining  systems  is  through  an  assessment  of  what  is 
required  to  exeeute  activities  as  defined  in  the  OV-5.  The  resulting  model  is  a  mapping  of 
systems  and  their  system  functions,  to  activities  in  an  Operational  Activity-to-Systems  Function 
Traceability  Matrix  (SV-5a)  and  an  Operational  Activity-to-Systems  Traceability  Matrix 
(SV-5b).  Coneurrent  with  the  construction  of  SV-5a  and  SV-5b  models  is  the  mapping  of 
systems  to  the  system  functions  (SV-4)  that  must  be  performed  for  mission  completeness. 
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Once  the  systems  necessary  to  execute  each  identified  aetivity  have  been  established,  but  not 
prior  to  establishing  those  systems,  each  system  may  be  related  through  an  SV-1.  Data  required 
to  generate  these  SV  produets  are  highlighted  in  yellow  in  Figure  13. 


Figure  13:  Primary  SV-1,  -4,  and  -5  Data  Elements  in  the  CBMM  Data  Model 


SV-1  generation  during  early  developmental  phases  may  still  be  beneficial  for  early 
planning,  eollaboration,  and  coordination  between  organizations.  If  the  SV-1  is  ereated  prior  to 
establishing  a  firm  understanding  of  the  activities  to  be  performed  and  the  performers  available 
for  the  mission,  the  arehiteet  must  articulate  to  leadership  the  high  likelihood  of  dramatic 
changes  in  the  interfaee  deseription. 


3,5  Modeling  Operational  Context  (OV-2,  -3,  -4) 

CBMM  does  not  have  any  unique  modifications  or  recommendations  for  construction  or 
management  of  either  the  resource  exehange  description  (OV-2)  or  a  resource  exehange  matrix 
(OV-3)  other  than  guidelines  already  provided  in  DoDAF  2.0.  Sinee  the  eommand  and  control 
structure  for  a  mission  and  the  available  resources  and  performers  are  often  established  by 
doetrine  or  current  Fleet  realities,  these  products  are  not  neeessarily  reliant  on  establishing 
capability  or  activity  taxonomies  for  generation.  For  this  reason,  CBMM  recommends  these 
viewpoints  be  drafted  and  updated  in  parallel  to  other  model  development  efforts.  The 
relationship  between  critieal  OV-2,  -3,  and  -4  data  elements  and  the  CBMM  data  model  is 
highlighted  in  yellow  in  Figure  14. 
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Figure  14:  Primary  OV-2,  OV-3,  and  OV-4  Data  Elements  in  the  CBMM  Data  Model 


3,6  Mapping  Systems  and  System  Functions  to  Capabilities  (CV-5) 

The  Organizational-to-Capability  Description  (CV-5)  can  be  tailored  to  model  which 
performers  or  organizations  are  responsible  for  a  given  capability  and  which  systems  they  use  to 
achieve  a  desired  effect.  Traditionally,  this  viewpoint  would  be  used  to  map  organizations 
responsible  for  executing  and  achieving  a  desired  effect.  In  CBMM,  tailoring  of  this  model 
encourages  mapping  technical  stakeholders  to  modeled  capabilities.  This  allows  the  architect  to 
establish  the  dependencies  of  primary  Fleet  stakeholders  on  the  technical  community.  In  the 
context  of  Fleet  exercise  and  experimentation  planning,  this  model  aids  in  determining  the  level 
of  impact  and  criticality  of  technical  organizations  to  the  larger  mission.  Data  required  to 
generate  these  products  are  highlighted  in  yellow  in  Figure  15. 
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Figure  15:  Primary  CV-5  Data  Elements  in  the  CBMM  Data  Model 


3,7  Optional  Technical  Requirements  and  Needs  Models  (SV-2,  -3) 

CBMM  maintains  no  unique  recommendations  or  guidance  toward  the  creation  of  the  System 
Resource  Flow  Description  (SV-2),  Matrix  (SV-3),  and  Systems  Functional  Description  (SV-4) 
but  does  recognize  them  as  critical  viewpoints  to  understanding  the  nature  of  systems  throughout 
the  mission.  These  resource-level  viewpoints  allow  program  offices  and  systems  engineers  to 
determine  how  a  particular  system  interacts  with  peer  systems. 


3,8  Optional  Operational  Mission  Threads  and  Effects  Chains  (OV-6  and  SV-10  Models) 

CBMM  recognizes  the  utility  of  mission  threads  (OV-6a,  OV-6c)  and  effects  chains  (SV-lOa, 
SV-lOc)  for  specific  purposes.  As  with  any  model,  CBMM  architectures  must  be  validated.  For 
computational  models,  the  modeler  can  validate  assumptions  and  algorithms  through  execution 
of  the  model  under  known  conditions  with  a  known  outcome.  Similarly,  an  architecture  can  be 
“executed”  by  forming  a  time-sequenced  thread  of  activities  or  chain  of  system  functions  that 
describe  how  activities  and  system  functions  are  executed  in  real  time  under  relevant  conditions. 
These  mission  threads  and  effects  chains  can  be  applied  to  Fleet  exercises,  simulations,  or 
operational  testing  where  the  conditions  of  the  events  are  clearly  understood.  By  verifying  events 
are  executed  as  the  mission  thread  or  effects  chain  indicated,  an  architect  can  validate  the  data 
and  data  relationships  contained  in  the  mission  architecture.  The  number  of  mission  threads  or 
effects  chains  necessary  to  validate  logical  data  relationships  in  an  architecture  depends  on  the 
comprehensiveness  of  each  thread  or  chain,  what  architectural  elements  have  already  been 
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validated  through  previous  arehiteetural  efforts  (using  the  modular  design  of  the  CV-6),  and  the 
desires  of  stakeholders  defined  in  the  AV-1. 

In  CBMM,  mission  threads  and  effects  chains  are  used  primarily  for  validation  and 
collaboration.  Validation  of  architectural  models,  communication  with  stakeholders  in  the 
technical  and  operational  domains,  and  quantifying  critical  mission  measures  are  all  useful 
applications  of  threads  and  chains.  If  the  questions  to  be  answered  and  objectives  in  the  AV-1 
have  been  appropriately  scoped,  these  threads  and  chains  can  also  be  effective  in  conceptualizing 
development  of  M&S  tools  to  feed  further  analysis.  What  is  not  encouraged  by  CBMM  is  the  use 
of  a  mission  thread  to  drive  or  scope  architectural  development.  A  mission  thread  may  contain  all 
activities  and  system  exchanges  that  occurred  during  a  single  instantiation  of  time,  but  that  does 
not  assure  the  thread  is  inclusive  of  all  possible  activity  and  system  relationships  that  may  exist 
throughout  the  enterprise.  Therefore,  the  architecture  must  be  driven  by  the  desired  effects 
articulated  by  the  Fleet  and  not  a  finite  set  of  time-sequenced  mission  threads  or  effects  chains. 

3.8.1  Mission  Thread  Example 

Deriving  Multiple  Surface  Warfare  Mission  Threads  from  One  Mission  Architecture 

Because  the  use  of  mission  threads  and  effects  chains  has  become  ambiguous  throughout  the 
architecture  community,  an  example  is  useful  in  understanding  why  CBMM  encourages  mission 
thread  generation  for  analysis  but  not  as  a  primary  driver  in  development. 

A  surface  action  group  (SAG)  is  typically  defined  as  a  grouping  of  surface  vessels  detached 
from  a  main  force  for  a  specific  mission,  using  assets  organic  to  or  directly  attached  to  any 
member  surface  platform.  This  may  include  helicopter  assets,  directly  attached  intelligence, 
surveillance,  and  reconnaissance  (ISR)  aircraft,  or  unmanned  systems.  Accordingly,  a  mission 
architecture  used  to  model  SAG  operations  for  a  given  Fleet  unit  should  include  all  activities 
conducted  by  each  of  these  nodes.  Not  every  excursion  a  SAG  undertakes  will  simultaneously 
involve  helicopters,  ISR  aircraft,  and  unmanned  systems.  Therefore,  an  architect  can  generate, 
from  a  comprehensive  SAG  mission  architecture,  individual  mission  threads  that  model  how  a 
SAG  would  use  an  ISR  aircraft  to  increase  fidelity  of  a  targeting  solution;  another  mission  thread 
to  show  how  unmanned  systems  can  augment  targeting  capabilities;  and  a  third  mission  thread  to 
show  how  helicopters  can  work  with  unmanned  systems  to  employ  a  coordinated  air-to-surface 
attack  on  a  surface  target.  Each  mission  thread  contains  its  own  unique  deadlines,  measures,  and 
sequence  of  events;  however,  the  relationships  between  activities  executed  by  each  performer  are 
all  derived  from  and  are  in  compliance  with  a  common  SAG  mission  architecture. 

This  example  demonstrates  that  a  single  mission  architecture  can  lead  to  multiple  mission 
threads.  Similarly,  by  identifying  the  systems  used  to  satisfy  each  activity  in  sequence,  multiple 
effects  chains  can  be  generated  to  show  the  different  ways  performers  may  use  material  solutions 
to  address  an  operational  need.  This  example  also  shows  how  any  single  mission  thread  or 
effects  chain  only  models  a  limited  subset  of  the  overall  mission  architecture,  and  that  any  single 
mission  thread  is  insufficient  for  modeling  end-to-end  mission  execution.  Had  the  architecture 
been  driven  by  a  single  thread  or  chain,  the  final  mission  architecture  product  may  have  omitted 
vital  platforms,  systems,  or  performers  otherwise  critical  to  overall  execution  of  the  mission  area 
and  achievement  of  larger  Fleet  capabilities. 
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3.8.2  Mission  Thread  Anaiysis  Discovery  of  Capabiiity  Gaps 

Using  mission  threads  and  effects  chains  to  define  critical  measures  and  to  communicate 
application  of  activities  and  systems  to  a  mission  can  result  in  identifying  and  characterizing 
capability  gaps.  Many  capability  gaps  are  the  result  of  poor  technical  requirements  that  manifest 
themselves  as  insufficient  technical  performance  throughout  mission  execution.  Since  mission 
threads  and  effects  chains  combine  systems  and  performers  across  programs  and  organizations  to 
demonstrate  how  they  support  a  mission,  these  threads  and  chains  become  effective 
communication  mechanisms  for  gap  demonstration  and  assessment. 

Whether  gaps  are  identified  through  assessment  of  threads  and  chains  or  whether  they  are 
known  prior  to  developing  the  architecture,  threads  and  chains  can  also  serve  an  important  role  in 
identifying  root  causes  and  effects  caused  by  deficiencies  in  critical  measures.  By  using  the 
critical  measures  and  associated  activities  or  functions  as  the  focal  point  of  a  thread  or  chain,  the 
architect  can  articulate  the  total  mission  impacts  as  a  result  of  a  specific  measure  value.  When 
paired  with  M&S  tools,  these  architectural  models  produce  a  blueprint  for  automated  gap 
analysis. 

3,9  Summary  of  Products  and  Supplemental  Products 

Table  1  lists  all  products  identified  as  critical  parts  of  CBMM  and  includes  a  list  of  optional 
viewpoints  with  their  related  data  elements.  These  models  are  considered  core  to  developing  an 
architecture  using  a  Fleet-first  approach. 


Table  1:  CBMM  Core  Models 


Modeling  Phase 

Viewpoint  Acronyms 
and  Names 

Suggested  Type 

Data  Elements 

Summary  and  overview  and 
scenario  documentation 

AV- 1 :  Overview  and 

Summary  Information 

Textual 

All 

OV-1:  High-Level 

Operational  Concept  Graphic 

Graphic,  textual 

Capabilities,  mission,  desired 
effect,  conditions,  doctrine 

Capability  definition  and 
mappings 

CV-2:  Capability  Taxonomy 

Node  tree 

Capabilities,  mission,  desired 
effect 

CV-4:  Capability 

Dependencies 

Functional  model 

Capabilities,  mission,  desired 
effect 

CV-6:  Capability  to 

Operational  Activities 

Mapping 

Functional  model 

Capabilities,  measures 

Activity  models 

OV-5a:  Operational  Activity 
Decomposition  Tree 

Node  tree 

Activities 

OV-5b:  Operational  Activity 
Model 

Functional  model 

Activities,  conditions,  people 
and/or  performers,  measures 

Operational  context 

OV-2:  Operational  Resource 
Flow  Description 

Varies 

People  and/or  performers, 
platforms,  resources 

OV-3:  Operational  Resource 
Flow  Matrix 

Matrix 

People  and/or  performers, 
platforms,  resources 

OV-4:  Organizational 
Relationships  Chart 

Node  tree 

People  and/or  performers, 
platforms 
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Modeling  Phase 

Viewpoint  Acronyms 
and  Names 

Suggested  Type 

Data  Elements 

Technical  mapping 

SV-5a:  Systems  Function 
Traceability  Matrix 

Matrix 

System  functions,  activities, 
resources,  measures 

SV-5b:  System  Traceability 
Matrix 

Matrix 

Systems,  activities,  resources, 
measures 

SV-4:  Systems  Functionality 
Description 

Varies 

Systems,  system  functions 

SV-1:  System  Interface 
Description 

Varies 

Systems 

Capability-system  mapping 

CV-5:  Capability  to 
Organizational  Development 
Mapping 

Matrix 

Capabilities,  systems,  system 
functions  (organizations  are 
part  of  AV-1  stakeholders) 

Optional  “for  purpose” 
models  (used  to  answered 
questions  documented  in 

AV-1) 

OV-6a:  Operational  Rules 
Model 

Textual 

Activities,  doctrine 

OV-6c:  Operational  Event- 
Trace  Description 

Swim  lane  chart  or  objective 
model 

Activities,  conditions,  people 
and/or  performers,  platforms, 
measures 

SV-2:  Systems  Resource 

Flow  Description 

Varies 

Systems,  resources 

SV-3:  Systems-Systems 

Matrix 

Matrix 

Systems 

SV-lOc:  Systems  Event- 
Trace  Description 

Varies 

System  functions,  conditions, 
people  and/or  performers, 
platforms,  measures 

Note  Table  1  omits  the  AV-2,  whieh  is  required  as  a  part  of  proper  DoDAF  2.0  arehitecture 
development.  The  integrated  dietionary  is  a  eore  viewpoint  in  any  integrated  architecture  but 
does  not  have  CBMM-unique  impacts  and  is  therefore  not  included  in  the  list  of  core  or  optional 
CBMM  models.  All  mission  architectures  should  comply  with  the  guidance  set  forth  by  the  DoD 
Chief  Information  Officer,  regardless  of  the  methodology  pursued. 

DoDAF  2.0  also  contains  numerous  viewpoints  not  identified  as  part  of  the  core  CBMM 
model  set  that  may  be  useful,  depending  on  the  specific  objectives  set  forth  in  the  AV-1.  It  is 
incumbent  upon  architects  to  determine  which  models  are  appropriate  to  obtain  answers  and  to 
achieve  goals  established  by  each  stakeholder. 

4,0  IMPACTS  ON  MISSION  ENGINEERING 

Architectures  are  built  for  the  purposes  defined  in  the  AV-1.  These  purposes  should  be  used 
for  analysis,  assessment,  evaluation,  or  requirements  definition  objectives  that  leverage  the 
powerful  data  management  schema  inherent  to  any  DoDAF  architecture.  Architectures  provide  a 
tool  for  managing  data  that  can  be  leveraged  for  mission  engineering  assessments  and 
evaluations,  but  only  if  mission  engineering  needs  are  clearly  articulated  upfront  in  the 
architectural  design  process. 

4.1  Defining  Mission  Engineering 

Mission  engineering  involves  planning,  analyzing,  organizing,  and  integrating  emerging 
operational  concepts  for  specifying  the  end-to-end  mission  architecture  attributes  across  the 
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DOTMLPF  spectrum.  These  mission  architectures  inform  the  communities  of  interest  involved 
in  fulfilling  mission  needs  statements  and  aid  in  the  identification  of  how  material  and  non¬ 
material  entities  contribute  to  the  Fleet’s  overall  desired  effect  of  Fleet  readiness. 

Historically,  requirements  definition  is  delivered  to  technical  stakeholders  through  a  series  of 
studies  and  reports  that  endeavor  to  translate  Fleet  needs  into  requirements  statements.  Engineers 
design  to  requirement  statements,  which  are  then  integrated  into  the  legacy  Fleet  enterprise. 

Since  the  technical  community  does  not  maintain  a  comprehensive.  Navy-wide  enterprise 
architecture  that  engineers  can  use  to  inform  their  development,  the  efficiency  at  which  an 
emerging  technology  can  be  integrated  with  the  Fleet  becomes  almost  entirely  dependent  on  the 
suitability  of  a  program’s  requirements  specifications.  Past  lessons  in  Navy  acquisitions  have 
shown  this  process  can  often  result  in  the  delivery  of  systems  for  operational  testing  or  initial 
operational  capability  that  fully  support  their  design  system  requirements  but  fail  to  adequately 
perform  mission  functions  essential  for  achieving  the  Fleet’s  desired  effects. 

Mission  architectures  provide  a  mechanism  for  managing  data  that  allows  the  technical 
community  to  clearly  understand  the  mission  context  in  which  a  system  will  be  expected  to 
operate.  By  maintaining  awareness  of  design  impacts  on  overall  mission  capabilities,  system 
requirements  can  evolve  as  threat  and  Fleet  capabilities  and  tactics  evolve.  System  requirements’ 
evolution  allows  technical  stakeholders  the  flexibility  and  knowledge  to  modify  or  adapt  system 
designs  to  better  anticipate  problems  with  integration  onto  a  platform,  into  a  fleet,  or  in  a 
specified  mission. 

4,2  Modeling  and  Tool  Development  Implications 

An  important  purpose  of  architecture  is  the  management  and  manipulation  of  data  originating 
from  numerous  data  sources  and  maintained  in  a  commonly  accessible  database.  By  centrally 
managing  multiple  stakeholders’  data,  individual  organizations  or  communities  of  interest  can 
access  data  from  other  sources  when  they  themselves  do  not  have  the  ability  to  collect  it.  Culture 
is  the  challenge  posed  to  the  architect  and  organizations  wishing  to  benefit  from  centralized  and 
common  data  management.  Development  and  analysis  teams  want  to  locally  manage  or  store 
data  related  to  their  tools  because  that  ensures  an  amount  of  control.  What  they  benefit  from  in 
control  they  lose  in  configuration  management  with  the  sources  from  which  the  data  originates. 
This  cultural  clash  between  central  data  management  and  a  preference  of  local  data  control  is  one 
that  risks  limiting  the  benefits  of  architectures  toward  informing  tool  development,  improving 
data  exchange  and  coordination  between  organizations,  and  integrating  available  modeling  tools 
to  produce  more  comprehensive  analysis. 

4.2. 1  Informed  Tool  De  velopment  and  Control 

Centrally  managed  data,  by  definition,  allows  data  subscribers  to  easily  determine  whether 
the  source  data  in  their  models  are  up  to  date  and  consistent  with  the  larger  enterprise.  Because 
the  data  is  actively  maintained  by  data  owners  and  architects,  users  can  identify  the  pedigree  of 
information  they  use  to  define  behavior  and  events  in  their  tools.  By  locally  controlling  data,  the 
onus  is  placed  on  each  development  organization  to  ensure  all  data  contained  in  their  models  are 
accurate  for  the  current  Navy  enterprise.  This  onus  translates  into  additional  expense  for  the 
sponsoring  organization  and  time  lost  from  development  and  analysis  tasks  that  must  now  be 
used  for  configuration  management.  Leveraging  a  mission  architecture  removes  this  onus  on 
each  individual  development  team,  resulting  in  a  higher  focus  on  development  and  analysis  and 
improved  development  cost  efficiencies. 
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4.2.2  Improving  Data  Exchange  and  Cross-organization  Coordination 


When  development  organizations  assume  the  responsibility  of  loeally  eontrolling 
information,  they  also  assume  the  role  of  gathering  and  ensuring  proper  eonfiguration  eontrol  of 
all  authoritative  data  (see  Figure  16). 


For  a  single  development  team  and  a  single  Fleet  organization,  this  level  of  data  exehange 
may  seem  trivial;  however.  Navy  realities  and  complexities  require  multiple  development  teams 
to  interact  with  numerous  Fleet  organizations  to  gather  and  exploit  all  information  necessary  to 
adequately  address  known  operational  deficiencies.  As  data  sources.  Fleet  organizations  are  now 
tasked  with  responding  to  often  similar  or  common  data  requests  from  numerous  organizations, 
as  illustrated  in  Figure  17.  Responding  to  these  requests  can  be  both  costly  and  divert  Fleet 
organizations  from  their  normal  operational  tasks.  In  some  cases.  Fleet  organizations  may 
become  so  overwhelmed  they  simply  cease  to  answer  redundant  data  requests. 
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From  individual  development  team's  perspective,  only  one  line  of  communication  is 
required  to  gather  data  from  a  data  originator. 


From  the  data  originator’s  perspective,  multiple  lines  of  communication  exist 
between  different  development  teams  that  require  similar  or  common  data  sets. 
This  means  redundant  coordination  and  tasking  on  the  part  of  each  data  originator. 


COHMAMM 


Figure  17:  Network  of  Development  Teams  Interacting  with  Numerous  Fleet  Organizations 

To  alleviate  requests  for  data  on  eaoli  data  source  and  ensure  no  development  teams  are  left 
without  vital  sources  of  validated  Fleet  data,  architecture  can  be  used  to  provide  a  single  point  of 
contact  for  both  Fleet  organizations  and  development  teams  as  shown  in  Figure  18. 


TACTICAL  DCVELOMCNT 
COMMANDS 


Figure  18:  Improved  Data  Exchange  Among  Fleet  Organizations,  Data  Originators,  and  Development  Teams 

The  resulting  enterprise  brings  improved  data  exchange  to  all  stakeholders  and  reduces  the 
need  for  redundant  lines  of  communication  between  organizations. 
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4.2.3  Tool  Integration 

Coordinating  modeling  efforts  can  become  complex.  Often,  development  teams  will  process 
a  list  of  analysis  objectives  and  propose  how  their  tool  might  address  part  or  all  of  stated 
problems.  Consolidating  the  strengths  and  weaknesses  of  each  modeling  team  becomes  complex 
and  coordinating  data  dependencies  between  each  individual  tool  to  solve  a  common  problem 
can  lead  to  problems  in  what  data  are  consumed,  how  they  are  processed,  the  assumptions  under 
which  each  model  is  executed,  and  the  conditions  under  which  each  model’s  output  is  valid. 

Because  architecture  data  is  integrated  per  the  CBMM  data  model,  data  needs  also  exist  in  an 
integrated  nature.  This  allows  engineers  and  analysts  to  more  objectively  identify  how  data 
should  be  exploited  before  selecting  a  tool  to  perform  the  required  operation.  Results  can  then  be 
used  to  address  analysis  objectives  or  fed  back  into  the  architecture  for  dissemination  to  all 
relevant  stakeholders. 


This  process,  shown  in  Figure  19,  is  referred  to  as  the  Mission-to-Model  process  and  includes 
developing  architecture,  planning  data  exploitation,  executing  exploitation  strategies,  developing 
comprehensive  analysis,  and  updating  architectural  databases. 


Figure  19:  CBMM  Mission-to-Model  Process  Graphic 


4,3  Capability  Gap  Analysis 

Identifying  capability  gaps  is  useful  for  all  domains  in  the  acquisition  triad  and  is  often 
performed  by  operational  forces  that  have  experienced  degraded  capabilities  while  executing 
training  or  operational  missions.  Architectures  possess  some  limited  ability  to  identify  new 
capability  gaps  by  establishing  connectivity  between  operational  activities  required  to  achieve  an 
overall  desired  effect  and  through  identifying  system-to-system  functions  that  must  be  executed 
throughout  the  mission.  By  analyzing  connectivity  between  activities  and  functions  and  the 
performance  required  of  each  data  element,  architects  can  identify  when  a  particular  activity  or 
function  is  either  not  executed  or  executed  under  unsatisfactory  conditions. 

Architectures  play  a  far  greater  role  in  aiding  in  the  characterization  and  analysis  of 
capability  gaps.  CBMM  begins  with  identifying  and  establishing  capabilities  required  to  achieve 
the  overall  desired  effect.  All  other  architectural  development  is  mapped  into  one  or  several 
initial  capabilities,  allowing  the  architect  to  clearly  identify  the  causes  and  effects  associated  with 
a  particular  activity  or  function  on  higher  level  capabilities.  By  identifying  a  known  capability 
gap,  architects  can  isolate  the  activities  and  functions  responsible  for  the  specified  capability, 
which  aids  in  focusing  analysis  and  M&S  efforts  required  to  assess  and  specify  a  solution  for  the 
gap.  Likewise,  analysis  efforts  that  originate  at  the  activity  and  system  functional  level  can  be 
mapped  into  known  capabilities  to  determine  if  a  modification  to  an  individual  operator, 
platform,  or  system  generates  a  new  potential  gap. 
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4,4  Recommended  Use  and  Appropriate  Application  of  Mission  Threads 

Common  use  of  mission  threads,  or  OV-6a  and  OV-60  DoDAF  models,  has  proven  effective 
in  commonly  communicating  architectural  data  across  a  wide  audience,  including  non-technical 
audiences  who  only  require  a  “big  picture.”  Unfortunately,  common  use  of  mission  thread 
models  has  also  created  an  abundance  of  architectures  that  represent  point-solutions  resulting 
from  driving  architectural  development  from  a  single  thread  rather  than  a  comprehensive  study 
of  all  capabilities  required  to  achieve  a  desired  effect.  For  this  reason,  CBMM  encourages  the 
use  of  mission  threads  and  effects  chains  for  communication,  collaboration,  and  validation  but 
not  as  a  means  to  drive  development. 

One  such  application  is  excursion  modeling,  or  modeling  of  a  single  instantiation  of  how 
mission  architecture  may  be  executed  given  a  set  of  initial  conditions.  Since  excursions  may  vary 
greatly  in  their  composition,  scope,  purpose,  and  other  architectural  factors,  it  is  impractical  for  a 
generic  architectural  methodology  to  specify  required  and  optional  viewpoints.  Each  viewpoint 
selected  for  the  excursion  should  be  derived  from  the  viewpoints  contained  in  the  parent 
architecture  and  selected  based  on  the  purpose  of  the  excursion.  The  only  requirement  that 
CBMM  places  on  generation  of  mission  threads,  effects  chains  (e.g.,  SV-lOc  viewpoints),  or 
other  architectural  models  is  that  they  have  a  clearly  defined  purpose  and  reference  the 
capability-driven  mission  architecture  from  which  they  are  derived.  CBMM  recommends  that  all 
excursions  mapped  to  a  specific  mission  architecture  be  identified  in  AV-1  addendums.  Placing 
excursion  descriptions  in  an  addendum  avoids  unnecessarily  increasing  AV-1  length  and 
complexity  but  reinforces  the  role  of  the  AV-1  to  shape  architectural  development  and  clearly 
define  analysis  objectives. 

The  purpose  for  developing  an  excursion  varies  with  each  architecture  product  and 
stakeholder.  Previous  Navy  I&I  experiences  have  found  excursions  useful  in  characterizing 
capability  gaps  that  only  present  themselves  during  specific  operational  conditions.  Other 
experiences  have  found  excursions  useful  in  proposing  and  coordinating  exercise  planning  with 
Fleet  elements.  The  purpose  and  desired  outcome  of  excursion  development  drives  which 
viewpoints  are  created  and  to  what  level  of  fidelity  each  viewpoint  must  be  developed. 

5.0  SUMMARY  AND  CONCLUSIONS 

CBMM  is  a  capability-based  modeling  methodology  that  encourages  architects  to  follow  a 
Fleet-first  approach  for  architectural  development  while  accommodating  data  sources  from 
across  the  Navy  and  greater  DoD  enterprise.  Using  CBMM  ensures  architectural  development  is 
appropriately  scoped  for  the  Fleet’s  overall  desired  effect  and  that  causes  and  effects  of  a  given 
action  are  clearly  understood  by  stakeholders  of  all  three  domains  represented  in  the  acquisition 
triad.  The  central  data  management  represented  in  CBMM  products  complements  open  data 
exchange  and  supports  improved  efficiencies  in  the  collaboration  and  use  of  M&S  tools.  When 
used  for  data  management  purposes,  CBMM  architectures  foster  a  greater  level  of  awareness 
among  Fleet  leadership,  operational  units,  and  SYSCOMs,  which  accommodates  development  of 
DOTMLPF  solutions  to  known  and  discovered  capability  gaps. 

Architecture  is  a  tool.  Tools  are  composed  of  materials  and  designed  for  a  purpose. 

DoDAF  2.0  provides  the  materials  to  build  Fleet- first  informational  tools,  and  CBMM  provides 
the  design.  By  using  CBMM  to  generate  Fleet-first  architectures,  future  acquisitions  can  be 
better  informed  by  warfighters’  needs,  resulting  in  more  efficient  system  deployment  and  force 
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integration.  These  improved  effieiencies  reduee  overall  Navy  costs  in  acquisition,  deliver  better 
equipment  to  operational  users,  and  ensure  a  more  ready  and  complete  Fleet  force. 
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